Flytta konfiguration mellan miljöer med Mover 1:1

 

Med verktyget Mover 1:1 förenklar ni er releasehantering i Easit GO genom möjligheten att flytta processer och flöden mellan miljöer. Att flytta processer och flöden skapar en trygghet eftersom det ni testat är exakt det som ni lyfter över från testmiljön till produktionsmiljön. Här har ni även möjligheten att schemalägga export av processer och flöden. Tack vare den funktionaliteten får ni en historik på hela designen, separerat från er data.

Med Mover 1:1 exporteras konfigurationen i ett Easit-system för att få en konfiguration som är identisk med källsystemet. Filen som skapas kallas snapshot och kan importeras till en annan miljö i samma instans, varvid målsystemet kommer att ha en konfiguration som är identisk med källsystemet, så när som på vissa systemunika parametrar såsom e-postserver, URL-er för webservice-integrationer mm. Dessa hanteras istället som miljövariabler i separata textfiler.

Därmed slipper man det dubbelarbete som tidigare har krävts i Easit då man till exempel konfigurerar nya funktioner i en testmiljö, och efter genomförda tester måste göra samma arbete i produktionsmiljön.

Det är dock inte alla konfigurationsobjekt som följer med vid ett ”Move”, som vi kallar det. De som inte följer med behöver därför konfigureras både i test- och produktionsmiljön, precis som tidigare. I avsnittet Vilken konfiguration följer med? finns en lista över vilka konfigurationsobjekt som följer med, och vilka som än så länge måste hanteras manuellt.

Mover 1:1 är en kraftfull funktionalitet som påverkar hela systemet. Easit rekommenderar att man följer en noggrann procedur för att inte riskera att försämra systemets funktionalitet.

En förutsättning är att man har minst en testmiljö (där ALL konfiguration och test görs) och en produktionsmiljö (där nästan ingen manuell konfiguration görs). Den enda konfigurationen som krävs i produktionsmiljön är för de konfigurationsobjekt som inte följer med i Mover 1:1, se avsnittet Vilken konfiguration följer med?. Med fördel har man även en eller flera utvecklingsmiljöer, där konfiguration kan utföras och sedan delexporteras till testmiljön.

Förberedande analys

Inledande analys av produktionsmiljön och iordningställande av testmiljön

Innan ni börjar använda Mover 1:1 eller Design Hub behöver en analys och städning göras av produktionsmiljön. När detta är klart, kan sedan testmiljön få samma städade konfiguration så att det är komplett och identisk konfiguration i båda miljöerna.

  1. Innan ni börjar analysen rekommenderar vi att ni tar en backup av databasen, både i källsystem och målsystem.

  2. Börja med att kontrollera om produktionsdatabasen innehåller flera objekt med identiska systemnamn, genom att öppna Mover 1:1 > Fliken Exportera design och klicka på knappen Kontrollera.
    Eventuella konflikter måste åtgärdas innan exporten kan genomföras.

  3. Därefter ska ett snapshot skapas från produktionsmiljön, genom att klicka på knappen Generera snapshot. Den första gången är detta ett sätt för att göra en städning i miljön och för att sätta systemnamn på all konfiguration innan det läggs in i testmiljön. Mer information om hur man skapar ett snapshot och hantering av de fel som kan uppstå finns längre ned i manualen.

  4. Efter att felen är hanterade och snapshot är skapat rekommenderar vi att ni tar en backup av produktionsdatabasen.

  5. Därefter är det dags att få testmiljön i samma skick som produktionsmiljön.
    Det kan göras på två sätt:

    a) Om ni endast vill importera konfigurationen, utan att data följer med så importerar ni snapshotet i testmiljön. Om det finns referenser till objekt eller användare kan ni behöva skapa upp dessa, se mer information om detta längre ned i manualen. Om ni i testmiljön även behöver ha konfiguration som inte följer med i Mover, t.ex. Mobilitet, Attest mm, (se avsnittet Vilken konfiguration följer med?) då behöver detta läggas in manuellt i testmiljön.

    b) För er som tillåter och vill att även data ska vara identiskt i de olika miljöerna kan istället en kopia av produktionssystemets databas läggas in i testsystemet.

  6. Efter detta steg är testmiljö och produktionsmiljö identiska avseende medföljande konfiguration (så när som på miljöspecifika inställningar som nämnts ovan).

Arbetsflöde

När käll- och målsystem har identisk konfiguration är det möjligt att börja arbeta enligt nedanstående arbetsflöde.

  1. Konfigurera ändringar och nya processer i test

    Hädanefter ska all konfiguration av systemet göras i testmiljön.

    Om man gör förändringar manuellt i produktion, kommer dessa att skrivas över när man importerar konfiguration från test. Detta kan behövas i undantagsfall, om man upptäcker allvarliga problem i produktion och inte kan vänta på att få en rättning utförd i test. Om man gör sådana akuträttningar i produktion, måste denna konfiguration delexporteras från produktion till test via Design Hub, annars kommer rättningen att skrivas över vid nästa import av snapshot.

    Konfiguration som inte följer med i Mover 1:1 behöver fortsättningsvis konfigureras både i test- och produktionsmiljön, det är exempelvis Objektbehörighet, Attestflöde och Mobila handläggargränssnittet.

  2. Kopiera konfiguration från test till produktion.

    Detta görs då ny funktionalitet konfigurerats färdigt och verifierats i test, så att den är redo att produktionssättas.

    Vi rekommenderar att ni börjar med att ta en backup av databasen, både i källsystem och målsystem.

    Därefter skapar man ett snapshot i test och importerar den till produktionsmiljön. Därmed är den nya funktionaliteten redo att användas.

Export av snapshot

Hur skapar jag ett snapshot?

Ett snapshot skapas i Easit GO under Kontrollpanelen > Mover 1:1 > Fliken Exportera design. Klicka på knappen Generera snapshot.

Kanske kommer åtgärder att krävas innan snapshotet är möjligt att skapa. Läs mer om detta under avsnittet Städning av konfiguration längre ned i manualen.

Om inga felaktigheter upptäcks i systemkonfigurationen skapas en fil med namn Snapshot_<aktuell tidpunkt>.xml. Notera att det kan ta några minuter att skapa snapshotet, beroende på hur mycket konfiguration som finns i systemet.

Import av snapshot

En del förberedelser behöver göras innan den skarpa importen kan göras. Öppna målmiljön och Kontrollpanelen >Mover 1:1 > fliken Importera design.

Kontrollera fil

För att säkerställa att alla refererande objekt/användare finns i målmiljön, kan du i fliken Importera design klicka på knappen Kontrollera fil. Läs mer om detta under avsnittet Referenser till objekt och användare längre ned i manualen.

Underhållsläge

Eftersom import av ett snapshot påverkar all konfiguration i systemet ska detta inte göras när det finns användare inloggade. Innan testkörning / import görs måste därför följande åtgärder vidtas:

  1. Aktivera underhållsläge. Detta gör att inga användare kan logga in samt att inga bakgrundsjobb kan startas förrän underhållsläget är avaktiverat igen.

  2. Se till att alla användare (utom den som ska genomföra importen) är utloggade. Detta kan kontrolleras i Kontrollpanelen > Behörighet > Inloggade användare, där man även kan logga ut användare.

  3. Kontrollera om det finns eskaleringar eller bakgrundsjobb som pågår. Detta görs i Kontrollpanelen >Inställningar > Generellt > Bakgrundsjobb. Avvakta tills pågående jobb är färdiga.

Hur testkör jag ett snapshot?

Vi rekommenderar att alltid testköra import av snapshotet, d.v.s. simulera importen, för att kontrollera hur resultatet skulle bli. Det gör du genom att klicka på knappen Testkör snapshot och leta upp ditt snapshot. Bekräfta genom att klicka OK i dialogen. Notera att testkörningen kan ta flera minuter, beroende på mängden konfiguration.

Resultatet av simuleringen visas i en trädstruktur grupperat på Åtgärd / Konfigurationstyp / Modul / Namn på konfiguration. Innehållet kan exporteras till Excel via knappen Exportera till Excel.

Åtgärd kan vara något av följande:

Ersatta
Visas för konfiguration som redan finns i målsystemet.
Vid en skarp import kommer dessa objekt att uppdateras i målmiljön, med eventuella förändringar som gjorts sedan senaste importen, t.ex. kolumner som lagts till i vyer, fält som lagts till i formulär mm. Notera att tidsstämplar för all ersatt konfiguration kommer att sättas till aktuell tidpunkt, och fältet Uppdaterad av kommer att sättas till den användare som utför importen (även om importen inte medför någon förändring av innehållet i konfigurationen).

Skapade
Visas för konfiguration som skapats i källmiljön sedan senaste import, t.ex. nya fält, formulär, vyer etc.
Vid en skarp import kommer dessa objekt att skapas i målmiljön.

Raderade
Visas för konfiguration som raderats i källmiljön sedan senaste import, t.ex. borttagna roller, rapporter, datakällor etc. Även konfiguration som skapats i målmiljön, men som inte finns i källmiljön, visas här.
Vid en skarp import kommer dessa objekt att raderas från målmiljön.

Efter utförd testkörning, om du inte ska göra en skarp import: avaktivera underhållsläget så att användare kan logga in, och bakgrundsjobb återigen tillåts köra.

Hur startar jag en skarp import?

Den skarpa importen startas genom att klicka på knappen Importera snapshot. Processen är identisk med en testkörning, förutom att ändringarna sparas i databasen.

Efter utförd import, avaktivera underhållsläget så att användare kan logga in, och bakgrundsjobb återigen tillåts köra.

Städning av konfiguration

Städning av konfiguration i källmiljön

Det finns olika typer av hinder för skapandet av ett snapshot: dubbletter av systemnamn samt konfiguration som hänvisar till annan konfiguration som har raderats. Om din miljö har något av dessa problem, behöver de åtgärdas innan snapshot kan skapas.

Dubbletter av systemnamn

Alla konfigurationer (t.ex. fält, formulär, objekttyper etc) som ingår i Mover 1:1 har ett systemnamn, som är en unik identifierare inom systemet. Systemnamnet används i Mover 1:1 för att hitta motsvarande konfiguration i målmiljön. Därför får samma systemnamn inte förekomma flera gånger inom en viss typ av konfiguration. För modulspecifik konfiguration gäller att systemnamnet måste vara unikt inom modulen. I vissa konfigurationsgränssnitt finns det inbyggt hinder för att återanvända samma systemnamn flera gånger, men inte överallt. Därför kan dubbletter förekomma. För att kontrollera om det finns dubbletter i systemet kan du på fliken Exportera design, använda funktionen Leta efter systemnamnskonflikter genom att klicka på knappen Kontrollera. Om det finns dubbletter visas dessa i en lista där du kan åtgärda problemen genom att ange nya systemnamn.

Raderade referenser

När alla dubbletter av systemnamn är lösta bör det gå att skapa ett snapshot. I vissa fall kan det dock förekomma att någon har raderat konfiguration som finns invald på andra ställen i systemet, t.ex. en roll som har behörighet i ett formulär. Om en sådan roll raderas tas inte kopplingen från formuläret till rollen bort, utan ligger kvar i databasen. Sådana kopplingar måste tas bort ur systemet innan ett snapshot kan skapas.

Om systemet innehåller raderade referenser visas en fellogg i ett popupfönster då man försöker skapa ett snapshot. I detta fönster listas de konfigurationer som raderats, och de konfigurationer som har beroenden till de raderade konfigurationerna. Samtliga fel som visas i fönstret måste lösas innan ett snapshot kan skapas. Det kan hända att felloggen dyker upp på nytt när du försöker skapa snapshotet, eftersom de rättningar du gjort i tidigare fellogg, kan göra att nya referenser blivit raderade eller att referenser som tagits fram ur papperskorgen i sin tur pekar på ytterligare raderade referenser.

Exempel på lista över raderade referenser som behöver åtgärdas.

I vissa fall kan detta göras automatiskt - i så fall visas en knapp till höger med namn Ta bort referens. Om du klickar på denna knapp kopplas den raderade konfigurationen bort. I vissa fall kan det vara så att man raderat konfiguration av misstag. Därför kan du även välja att återställa den raderade konfigurationen genom att klicka på knappen Visa i papperskorg. Detta öppnar Papperskorg för konfiguration i en ny flik i webbläsaren.

I de fall en automatisk korrigering inte kan göras, måste den raderade referensen hanteras manuellt.

Exempel: Låt säga att systemet innehåller ett formulär som använder sig av en raderad vy i funktionen Underobjekt. I så fall visas en knapp som tillåter dig att öppna admin för formulär till höger om formulärets namn. Klicka på knappen för att öppna formuläradmin i en ny webbläsarflik. Sök fram aktuellt formulär och leta på referensen till vyn, t.ex. genom att öppna konfigurationen för Underobjekt. Välj en ny vy och spara formuläret.

I vissa fall kan det räcka att öppna administrationen för den aktuella konfigurationstypen, och gå in och spara om konfigurationen i fråga. Ett exempel är Formulärläge. Om en objekttyp tagits bort ur systemet kanske det i databasen finns en inställning för Formulärläge som fortfarande pekar på den raderade objekttypen. Om man öppnar administration av Formulärläge och klickar Spara-knappen kommer denna referens att tas bort under ytan. Detta kan även uppstå i Vyer – Sortering och synlighet om en vy är raderad.

Övriga fel

I vissa undantagsfall kan det uppstå andra typer av problem då man försöker skapa ett snapshot. Ett exempel är om man har rapporter i systemet som använder sig av filer, och någon av dessa filer har raderats i filsystemet. Sådana fel visas i en separat flik Övriga fel. Kontakta Easit om du stöter på felmeddelanden i denna flik, som du inte vet hur du ska hantera.

Ett annat exempel på ett övrigt fel kan vara en referens till en raderad användare eller ett raderat objekt, till exempel en organisation eller kontakt. I vissa fall kan det förekomma att konfiguration refererar till objekt eller användare, till exempel om man har vyer för att visa ärenden för en viss organisation (objekt), eller en vy över användare som filtrerar mot en viss chef (användare). Om man har sådan konfiguration, och objektet / användaren som konfigurationen pekar på har raderats, måste detta hanteras på samma sätt som raderad konfiguration. Dessvärre går detta ej att göra direkt från felloggen, utan måste göras manuellt. Raderade objekt och användare kan återställas från Papperskorg för objekt.

Systemdold konfiguration

Ditt system kan innehålla konfiguration som är dold. Detta är något Easit använder sig av för att dölja processer och funktionsområden som inte har aktiverats. Ett exempel kan vara en kund som endast använder Incident-processen i Ärendemodulen, varvid övriga ärendeprocesser (Problem, Händelse etc) är dolda. Att en process är dold innebär att det inte går att se de formulär, fält, regler, vyer etc som ingår i processen. Det är endast Easit-personal som kan aktivera dold konfiguration, och normalt kan kunder inte se den.

Ett undantag från denna regel är när man arbetar med snapshots. För att ett snapshot ska vara komplett måste den innehålla all icke-raderad konfiguration i källsystemet - inklusive dold konfiguration. I vissa fall kan detta kräva att den som skapar ett snapshot måste kunna korrigera dolda konfigurationer, om dessa ingår i listan av raderade referenser. Här är några exempel:

Exempel: Det finns ett dolt formulär som pekar på ett raderat fält. Låt oss säga att det dolda formuläret Problem innehåller fältet Referens organisation, som har raderats - kanske för att det inte behövdes i Incidentformuläret.

  • Alt 1: Återställ fältet Referens organisation genom att öppna Papperskorgen

  • Alt 2: Radera det dolda formuläret Problem genom att klicka på minus-knappen i felloggen

Referenser till objekt och användare

Vissa typer av konfiguration kan innehålla referenser till objekt (t.ex. ärenden, organisationer etc) och användare, till exempel om man har vyer för att visa ärenden för en viss organisation (objekt). Eftersom objekt och användare i sig inte följer med i snapshotet, kräver sådana referenser lite manuellt jobb vid importen.

Då man skapar ett snapshot som innehåller referenser till objekt eller användare visas ett fönster efter att snapshotet skapats. I detta fönster visas vilka objekt och användare som refereras till i snapshotet. I listan visas modul, objekttyp, id, visningsnamn samt UUID (Universellt Unikt ID). Listan kan exporteras till Excel. För att snapshotet ska gå att importera måste samtliga användare och objekt även finnas i målmiljön. Med detta menas att det måste finnas objekt med samma objekttyp och UUID, samt användare med samma UUID. Övriga uppgifter för objekten och användarna kan skilja mellan miljöerna om så önskas.

UUID är en unik identifierare för ett objekt eller en användare. Om UUID saknas på objekt/användare så genereras det automatiskt när de sparas. Om man vill tillåta användare att redigera UUID måste behörighet ges till detta i systemet:

- UUID för användare: ge token "Administration - Användare - UUID" till berörd roll

- UUID för objekt: ta fram det interna fältet UUID på formulär och ge access till detta fält till en roll som ska ha rätt att redigera UUID

Notera att värdet på UUID måste uppfylla följande villkor:

- Det måste vara unikt inom ett system. Exempelvis kan en organisation inte ha samma UUID som en användare.

- Det måste ha korrekt format. Ett UUID består av hexadecimala siffror (0-9, a-f) och finns beskrivet i RFC4122: https://tools.ietf.org/html/rfc4122

Exempel: Låt säga att det i en produktionsmiljö finns en användar-vy som heter "Anita Svenssons anställda". Vyn är konfigurerad att visa vilka användare som har Anita Svensson som chef, genom att vyn innehåller filtret "Närmaste chef = Anita Svensson". Detta är en vy med en referens till en användare, närmare bestämt Anita Svensson, som (låt oss säga) har UUID 7326bc4d-9089-49d3-aec4-79a46f52dbb4. Låt oss även säga att det i produktionsmiljön finns en vy i kontaktmodulen som heter "Anställda på Easit AB". Vyn är konfigurerad att visa vilka kontakter som tillhör organisationen Easit AB, genom att den innehåller filtret "Organisation = Easit AB". Detta är en vy med en referens till ett objekt, närmare bestämt organisationen Easit AB, som (låt oss säga) har UUID 7428d389-66dc-4e00-9c9e-5cffb2d3e373.

När ett snapshot skapas i denna miljö visas Anita Svensson och Easit AB i listan över användare och objekt som refereras i snapshotet, inklusive deras namn (Anita Svensson / Easit AB) och UUID (7326bc4d-9089-49d3-aec4-79a46f52dbb4 resp 7428d389-66dc-4e00-9c9e-5cffb2d3e373).

Om ni har en testmiljö som innehåller de faktiska användarna och objekten, d.v.s. en kopia av produktionsmiljön, så bör ju användare/objekt redan finnas med samma UUID i båda miljöerna. Då behöver det manuella arbetet inte göras innan importen.

Om du ska importera detta snapshot i en testmiljö (som inte har samma data som i produktion) behöver dessa användare/objekt även finnas där, då behöver ni skapa motsvarande data i testmiljön innan import. I detta läge krävs det endast att UUID är korrekta. Namnen (Anita Svensson respektive Easit AB) kanske man inte vill ha i testmiljön, eftersom de innehåller personuppgifter. Döp i så fall om dessa till något anonymt, t.ex. Test Testsson, och organisationen till Företaget AB. Om ni inte skapar de objekt som saknas kommer detta behöva göras senare som ett steg när snapshotet importeras, se mer information nedan.

UUID för objekt ingår i index för systemets sökfunktion, och därför går det att söka upp objekt (organisationer, ärenden, kontakter etc) genom att söka på UUID i supersök. Om man vill söka upp en användare som har ett visst UUID måste man skapa en användar-vy som innehåller kolumnen UUID. I administrationen av användare kan man sedan välja denna vy och ange ett filter i fältet UUID.

Om det saknas användare eller objekt i målmiljön då ett snapshot importeras, kommer ett fönster att visas och importen avbryts. Fönstret innehåller en lista över saknade användare och objekt. I listan visas modul, objekttyp och UUID. Till höger i respektive rad i listan visas en Skapa-knapp, som man kan använda om man vill skapa objekt med rätt modul, objekttyp och UUID, eller användare med rätt UUID. När du klickar på Skapa-knappen skapas ett nytt objekt / en ny användare (med rätt UUID) som sparas direkt i databasen. Objektet / användaren öppnas därefter i en ny flik, så att du kan fylla i övriga uppgifter, t.ex. för- och efternamn för användare samt fältinnehåll för objekt (namn på kontakter, organisationer, rubrik på ärenden etc.).

Det kan finnas användare som behöver skapas med några fler inställningar än andra. Det är t.ex. Självserviceanvändaren. Om denna användare saknas i målmiljön är det viktigt att tänka på att ge de rättigheter användaren behöver ha för att inloggning ska kunna göras i Självservice.

Om ett objekt hör till en objekttyp som inte finns i målmiljön, kommer objekttypen att skapas, så att det nya objektet får rätt objekttyp. I detta fall går det dock inte att redigera innehållet i objektet, eftersom objekttypen inte kommer att ha något formulär att arbeta i förrän snapshotet är importerat. Detta kan hända t.ex. om man har konfigurerat upp en ny process i testmiljön, med nya objekttyper, och nya konfigurationer som använder objekt av dessa typer.

Om du importerar ett snapshot med en referens till ett objekt som finns i målmiljön med rätt UUID, men med fel objekttyp (dvs en annan objekttyp än den i källsystemet), visas ett felmeddelande om att objektet i målmiljön har fel objekttyp. I detta fall måste du antingen korrigera objekttypen i källmiljön (och skapa ett nytt snapshot) eller korrigera objekttypen i målmiljön.

Om du vill kontrollera snapshotet och säkerställa att alla refererande objekt/användare finns i målmiljön, kan du i fliken Importera design klicka på knappen Kontrollera fil. Ladda upp det snapshot du vill kontrollera. Ingen import görs, utan endast en kontroll av att användare/objekt i filen finns i målmiljön. Om det saknas något visas dialog enligt ovan, där du kan skapa de objekt/användare som saknas.

Skapa automatiska snapshots

Om du vill att snapshots ska genereras regelbundet, med automatik, kan du sätta upp ett bakgrundsjobb. Bakgrundsjobbet sparar designen i xml-format som den ser ut vid körningstillfället. Läs mer om hur du sätter upp bakgrundsjobb i manualen Administrera bakgrundsjobb.

Inga andra jobb får köras samtidigt som snapshotet skapas, så se till att schemalägga det vid en tidpunkt då inga andra jobb är schemalagda, och när inga användare är inloggade.

De snapshots som genereras av bakgrundsjobbet kan laddas ner från fliken Autogenererade snapshots i gränssnittet för Mover 1:1.

Automatisk import av snapshots

Genom att, på fliken Importera design, aktivera Automatisk import är det möjligt att importera konfiguration vid uppstart av systemet. Detta kräver att ett snapshot finns i mappen design_mover/import_autostart, som ligger i den konfigurationsmapp som ställts in vid installation av Easit GO. Mappen import_autostart skapas när du aktiverar Automatisk import, om den inte redan finns.

Om det finns mer än ett snapshot i denna mapp kommer ingen automatisk import att göras.

Viktigt vid import

Versionsnummer

Snapshotet innehåller versionsnummer för den version av Easit GO som är installerad i systemet där snapshotet skapades. När snapshotet importeras görs en kontroll att versionsnumret i filen är samma som versionen hos det system importen görs till. Om versionerna skiljer sig åt visas en feldialog och importen avbryts. Anledningen till detta är att det inte finns någon garanti för att ett snapshot från en annan version går att importera. Om du råkar ut för detta är vår rekommendation att du uppgraderar dina Easit-system så att de har samma version, innan du fortsätter arbeta med Mover 1:1.

Notera att import fungerar mellan olika patch-nivåer av samma version – om du t.ex. har 2020.05 patch 1 i produktion och 2020.05 patch 4 i test, går det bra att importera mellan miljöerna.

Instans-id

Snapshotet innehåller en företagskod, s.k. instans-id, som visar vilket system som konfigurationen tillhör. Det går endast att importera snapshotet till miljöer med samma instans-id, vilket kan vara mellan Produktion – Test – Utveckling.

Minnesförbrukning

Export och import av snapshots förbrukar ganska mycket av datorns minne. Därför kan det krävas att man tilldelar Tomcat mer minne om man vill börja arbeta med Mover 1:1.

Filstorlek

Ett snapshot kan bli ganska stort. I vissa fall kan det bli problem att ladda upp filen p.g.a. begränsningar i webbservern. Om du stöter på detta kan lösningen vara att ställa in så att IIS tillåter större filer alternativt ladda upp filen direkt till Tomcat istället för via IIS.